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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the Service Change and UDI Fallback (SCUDIF) feature. This service is available to 
UDI/RDI multimedia calls and allows users to achieve successful call establishment when end to end circuit-switched 
(CS) multimedia is not possible (fallback to speech) or when signalling of the feature is not possible in the network 
(fallback to preferred service or speech). Furthermore, it allows the users to swap between a multimedia service and 
basic speech during an established call. 

NOTE: In the present document, the term "multimedia" refers to UDI/RDI multimedia unless specifically stated. 



2 References 

The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.153: "Out of Band Transcoder Control; Stage 2". 

[3] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core network protocols; 

Stage 3". 

[4] 3GPP TS 26.103: "Speech Codec List for GSM and UMTS". 

[5] 3GPP TS 27.001 : "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[6] 3GPP TS 29.007: "General requirements on interworking between the Public Land Mobile 

Network (PLMN) and the Integrated Services Digital Network (ISDN) or Pubhc Switched 
Telephone Network (PSTN)". 

[7] 3GPP TS 29.205: "Application of Q. 1900 series to bearer-independent circuit-switched core 

network architecture; Stage 3". 

[8] 3GPP TS 22.101: "Service aspects; Service principles". 

[9] 3GPP TS 33.106: "3GPP Security; Lawful Interception Requirements". 

[ 1 0] 3GPP TS 23 .0 1 8 : "Basic Call Handling; Technical realization" . 

[II] 3GPP TS 23 .003 : "Numbering, adressing and identification" . 

[12] 3GPP TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW) Interface; 

Stage 3". 

[13] 3GPP TS 26.102: "Mandatory Speech Codec; AMR Speech Codec; Interface to lu, Uu, Nb". 

[14] 3GPP TS 23.078: "Customised AppHcations for Mobile network Enhanced Logic (CAMEL) ; 

Stage 2". 

[15] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services. Stage 2". 

[16] 3GPP TS 22.078: "Customised AppUcations for Mobile network Enhanced Logic (CAMEL); 

Service description. Stage 1". 
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[ 1 7] 3GPP TS 25 .4 1 3 : "UTRAN lu interface RANAP signalling" . 

[ 1 8] IETF RFC 4040: "RTF Payload Format for a 64 kbit/s Transparent Call" 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

fallback: when two services (multimedia and speech) are proposed but only one of them is available or wanted, only 
the service available (preferred or less preferred) is selected, and the other one is discarded 

service change: when two services (multimedia and speech) are available during the active state of a call, users may 
request a service change to switch between the two services 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

BC Bearer Capability 

BCl First Bearer Capability in a message (preferred service) 

BC2 Second Bearer Capability in a message (less preferred service) 

BCa Bearer Capability of the currently selected service 

BCb Bearer Capability of the service to switch to 

BCmm Bearer Capability multimedia 

BCSM Basic Call State Model 

BCsp Bearer Capability speech 

CAMEL Customised Applications for Mobile network Enhanced Logic 

DP Detection Point 

IE Information Element 

MMI Man-Machine Interface 

O-MSC Originating MSC 

OoBTC Out-of-Band Transcoder Control 

O-UE Originating UE 

RI Repeat Indicator 

SCUDIF Service Change and UDI/RDI Fallback 

T-MSC Terminating MSC 

T-UE Terminating UE 

4 Service ciiange and fallback for UDI/RDI multimedia 



4.1 General Requirements 



The Service Change and UDI Fallback (SCUDIF) is a function which applies to UDI/RDI multimedia calls (see 
3GPP TS 22.101 [8], clause 7.2.1), and shall support the following: 

a) Fallback to speech during call setup: allow a user to attempt to set up a multimedia call, and try a speech 
connection if the former doesn't succeed; 

b) Fallback to the less preferred service (speech or multimedia) during call setup: allow the terminating side via 
specific settings for this service in the terminal to accept or reject a multimedia call, without interrupting the call 
setup; 

c) Fallback to the preferred service (speech or multimedia) or speech during call setup: allow the call setup to 
proceed with a single service if the transit network does not support the signalling of this functionality; 
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d) BC negotiation at the terminating side: allow the terminating side via specific settings for this service in the 
terminal to turn a speech call (with service change) into a multimedia call and vice-versa; 

e) Service change: allow a speech call to be turned to multimedia by either of parties, and back to speech, through a 
successful in call modification procedure; 

f) Allow any of the users to reject a multimedia request from the other party while in speech mode. 

g) Network-initiated service change: The network shall initiate a sevice-change from multimedia to speech during 
the active call if a multimedia call can no longer be supported. If a multimedia call can again be supported at a 
later point in time, the network may initiate a service change from speech to multimedia. 

To fulfil: 

service request signalling between the UE and the MSC; 

service request signalling across the Core Network. 

This functionality is not supported for multimedia with Fixed Network User Rate set to 32 kbit/s. In this case, the MSC 
shall revert to a multimedia only call. 

4.2 Access Call Control Signalling 

Using the repeat indicator value "support of service change and fallback", as described in 3GPP TS 24.008 [3], 
clause 5.3.6, together with two BC-IEs, a multimedia and a speech, it is possible to request a service change and 
fallback functionality, while still maintaining the backwards compatibility with non-supporting terminals. 

4.2.1 Mobile originating side - initiation of call setup 

By sending a SETUP message with a Repeat Indicator set to "support of service change and fallback", a multimedia 
BC-IE, and a speech BC-IE (see figure 4.1), a terminal may request a call to be set with the capability to fallback to 
either a speech only, a multimedia only call or to use service change later during the active state of the call (the first 
BC-IE indicates the preferred service). If the terminal supports Network-initiated service upgrade to multimedia, then it 
shall also indicate this in the SETUP message with the "Enhanced Network-initiated ICM" (ENICM) Capability (see 
3GPP TS 24.008[3]). 

After checking the provisioning (see subclause 4.2.1.1), and verifying that the functionality is supported, the MSC 
replies in the CALL PROCEEDING message with either the two BCs in the same order (to indicate that it accepts the 
proposed settings - see figure 4.2), or with a single BC (multimedia or speech - see figure 4.3) unless the CALL 
PROCEEDING is delayed until the response from the terminating user and then it may also be sent with the BCs in 
reverse order (see clause 4.2.3). 

In the case the MSC ignores the SETUP message if the presence of a reserved value for the Repeat Indicator is set, it 
sends a STATUS message back to the UE (see figure 4.4), with the Cause Value set to #100, "Conditional IE error" (see 
3GPP TS 24.008 [3], clause 8.7.2). The UE then reacts as described in 3GPP TS 24.008 [3], clause 5.5.3.2.2, and may 
resend a new SETUP message with a single BC, or perform any appropriate action according to its implementation. 
This also applies in case the MSC returns instead a RELEASE COMPLETE message. 



0-UE 



0-MSC 



SETUP (Rl, BC1, BC2, [ENICM]) 



Figure 4.1 : SETUP message towards the originating IVISC 
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0-UE 


CALL PROCEEDING (Rl, BC1, BC2) 


0-MSC 












* 









Figure 4.2: Normal case 



O-UE 




0-MSC 






CALL PROCEEDING (BC1 or BC2) 








* 









Figure 4.3: Fallback case 



O-UE 



STATUS (Cause:#1 00) 



SETUP (BCI or BC2) 



CALL PROCEEDING (BC) 



0-MSC 



NOTE 



NOTE 



NOTE: The sending of the STATUS message from the MSC and the second SETUP message from the UE are 
implementation dependent. 

Figure 4.4: IVISC not supporting the Rl value 



4.2.1.1 



Subscription checl^ing 



The functional behaviour of the originating MSC and VLR is specified in 3GPP TS 23.018 [10]. The procedure specific 
to SCUDIF is specified in this subclause: 

For mobile originated SCUDIF calls, the MSC shall convert both PLMN bearer capability 1 and PLMN bearer 
capability 2 to two individual Basic Service codes and send them in Send Info For Outgoing Call. The VLR shall check 
the subscription for those basic services, then indicates the availability of each basic service to the MSC by Complete 
Call. If both services are not provisioned, the VLR shall send Send Info For Outgoing Call negative response to the 
MSC. The MSC shall fall back to the allowed service if the availability of only one service is indicated. The MSC shall 
continue as a SCUDIF call if the availability of both services is indicated. 



4.2.1.1.1 



Send Info For Outgoing Call 



Send Info For Outgoing Call contains the following SCUDIF specific information elements: 



Information element name 


Status 


Description 


Bearer service2 


C 


Bearer service 2 required for the IVIO call, derived from the PLMN 
bearer capability 2 information received in the set-up request from 
the IVIS. For a SCUDIF call, one of bearer service 2 or teleservJce 
2 shall be present. 


Teleservice2 


C 


Teleservice 2 required for the IVIO call, derived from the PLIVIN 
bearer capability 2 information received in the set-up request from 
the IVIS. For a SCUDIF call, one of bearer service 2 or teleservice 
2 shall be present. 
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4.2.1.1.2 



Complete Call 



Complete Call contains the following SCUDIF specific information elements: 



Information element name 


Status 


Description 


First service availability 


C 


Shall be present for a MO SCUDIF call if the Bearer service or 
Teleservice is allowed; otherwise shall be absent. 


Second service availability 


C 


Shall be present for a IVIO SCUDIF call if the Bearer service 2 or 
Teleservice 2 is allowed; otherwise shall be absent. 



4.2.2 Mobile terminating side 



When the terminating MSC receives a request for a multimedia call, it shall check if the called user is provisioned for 
the service (see subclause 4.2.2.1). 

The terminating MSC shall include in the SETUP message towards the UE both BC-IEs in the same order as indicated 
by the incoming request together with the Repeat Indicator set to "service change and fallback in order to invoke the 
SCUDIF functionality in the called terminal (see figure 4.5). 

The terminating UE, based on its capabilities and internal settings, may return the two BC-IEs in the same order (to 
indicate that it accepts the proposed settings - see figure 4.6), reversed order (see figure 4.7), or just one BC-IE (either 
speech or multimedia - see figure 4.8) to the terminating MSC in the CALL CONFIRMED message. If the terminal 
supports Network-initiated service upgrade to multimedia, then it shall also indicate this in the CALL CONFIRMED 
message with the"Enhanced Network-initiated ICM" (ENICM) Capability (see 3GPP TS 24.008[3]). 

In the case the UE ignores the SETUP message due to the presence of a reserved value for the Repeat Indicator, it sends 
a STATUS message back to the terminating MSC (see figure 4.9), with the Cause Value set to #100, "Conditional IE 
error" (see 3GPP TS 24.008 [3], clause 8.7.2). The terminating MSC shall then react according to 3GPP TS 24.008 [3], 
clause 5.5.3.2.2 and it shall send a new SETUP message with a single BC, either the preferred service BC-IE or the 
speech BC-IE (fallback to speech), depending on configuration. The call setup then proceeds accordingly. 



T-MSC 



T-UE 



SETUP (Rl, BC1, BC2) 



Figure 4.5: SETUP message towards the terminating UE 



T-MSC 




T-UE 




CA 


LL CONFIRMED (Rl, BC1, BC2, [ENICM]) 

















Figure 4.6: Normal case 



T-MSC 




T-UE 






CALL CONFIRMED (Rl, BC2, BC1) 

















Figure 4.7: Reversed call setup 
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T-MSC 




T-UE 






CALL CONFIRMED (BC1 or BC2) 








■^ 









Figure 4.8: Fallback case 



T-MSC 



STATUS (Cause: #100) 



SETUP (BC1 or BC2) 



CALL CONFIRMED (BC ; 



T-UE 



Figure 4.9: UE not supporting the Rl value 



4.2.2.1 



Subscription checking 



The functional behaviour of the terminating MSC and VLR is specified in 3GPP TS 23.018 [10]. The procedure 
specific to SCUDIF calls is specified in this subclause. 

For mobile terminating SCUDIF calls, the MSC shall convert the services received in the incoming request to two 
individual Basic Service codes, and include them in Send Info For Incoming Call. The VLR shall check the subscription 
for those basic services, then indicate the availability of each basic service to the MSC by Complete Call. If both 
services are not provisioned, the VLR shall send Send Info for Incoming Call negative response to the MSC. The MSC 
shall fall back to the allowed service if the availability of only one service is indicated. The MSC shall continue as a 
SCUDIF call if the availability of both services is indicated. 

4.2.2.1 .1 Send Info For Incoming Call 

Send Info For Incoming Call contains the following SCUDIF specific information elements: 



Information element name 


Required 


Description 


Bearer Service 2 


C 


Bearer Service 2 required for the IVIT call, derived from the less 
preferred service indicated in the incoming lAM of a SCUDIF call. 
For a SCUDIF call, one of Bearer service 2 or Teleservlce 2 shall 
be present. 


Teleservlce 2 


C 


Teleservlce 2 required for the IVIT call, derived from the less 
preferred service indicated in the incoming lAM of a SCUDIF call. 
For a SCUDIF call, one of Bearer service 2 or Teleservlce 2 shall 
be present. 



4.2.2.1.2 



Complete Call 



The parameters described in subclause 4.2.1.1.2 "Complete Call" for the mobile originating MSC are also applicable to 
the mobile terminating MSC. 

4.2.3 Mobile originating side - completion of call setup 

If the preferred mode, that is the first BC-IE indicated by the originating UE, was selected as the result of negotiations, 
the call shall be set up normally towards the originating UE. 
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If the negotiation resulted in a change of the selected mode, i.e. the call was set up as "multimedia first" and changed 
during the negotiation to a speech call, or vice-versa, because of either fallback or change of selected mode and the Call 
Proceeding message has been sent then an In-Call Modification procedure (see 3GPP TS 24.008 [3], clause 5.3.4.3) 
shall be initiated towards the originating UE after the call control entity has entered the active state, i.e. the CONNECT 
message has been sent. 



0-UE 



0-MSC 



CONNECT 



CONNECT ACKNOWLEDGE 



Figure 4.10: Preferred mode selected 



O-UE 



CONNECT 



0-MSC 



CONNECT ACKNOWLEDGE 



MODIFY {BC2) 



MODIFY COMPLETE (BC2) 



Figure 4.11 : Less preferred mode selected, accepted 



O-UE 



CONNECT 



0-MSC 



CONNECT ACKNOWLEDGE 



MODIFY (BC2) 



MODIFY REJECT (BC1) 



RELEASE COMPLETE 



Figure 4.12: Less preferred mode selected, rejected 

If the Call Proceeding message is delayed until response from the terminating side then it may include one or both BCs 
either in the order requested from the Originating UE or the order of the BCs may be reversed, depending on the result 
from the negotiation or (single EC) due to fallback. See Figure 4.12a. 
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O-UE 



:ALL proceeding (RI, BC2, BC1) 



0-MSC 



CONNECT 



CONNECT ACKNOWLEDGE 



(select = X, avail = x, y, z, mm) 



Figure 4.12a: Call Proceeding Delayed 

4.2.4 User-initiated Service cinange in tine active state 

At any given time, if either of the call parties wants to change from the current active mode to the other mode via MMI, 
the terminal shall activate an In-Call Modification procedure. Using this procedure, described in 3GPP TS 24.008 [3], 
clause 5.3.4.3, the UE shall send a MODIFY message containing the BC-IE to change to. This BC-IE shall be one of 
those already negotiated at call setup. 

As a result, the MSC shall then invoke the service change procedure (see clause 4.3.5). If the request is accepted, the 
originating MSC sends a MODIFY COMPLETE message to the UE including the BC-IE of the mode to switch to (see 
figure 4.13). If the request is rejected, the MSC sends a MODIFY REJECT message to the UE including the BC-IE 
from the current active mode (see figure 4.14). 

In the case the MSC has determined that the other mode is unavailable (e.g. a fallback to either mode has occurred), it 
shall reject the MODIFY request at once by replying with a MODIFY REJECT message. 

On the remote side, the MSC shall initiate an In-Call Modification procedure towards the terminal using the MODIFY 
message. For a service change from speech to multimedia, the terminal shall request confirmation from the user unless 
configured differently. For a service change from multimedia to speech, the terminal shall accept the request without 
requesting confirmation from the user. If the change is accepted, the UE shall reply to the MSC with a MODIFY 
COMPLETE message, whereas a MODIFY REJECT message shall be sent if the change is rejected. 

NOTE: Privacy concerns strongly advise that any change to multimedia mode, unless explicitly allowed by the 

user in the terminal configuration settings, triggers a question to the user in order to confirm or decline the 
change. The details on how to provide the user interaction are left for implementation. 

When receiving a MODIFY message, a terminal shall not interrupt the data traffic and shall continue to send and 
receive data in the old mode, even after the terminal accepts the modification with a MODIFY COMPLETE message. 
The radio bearer will then be reconfigured by the network. After the radio bearer has been reconfigured, the terminal 
shall send and receive data in the new mode. 



UEA 



MSC A 



MODIFY (BCb) 



MODIFY COMPLETE (BCb) ^: 



MSCB 



Core Network 
Procedure 



Core Network 
Procedure 



UEB 



MODIFY (BCb) 



MODIFY COMPLETE (BCb) 



Figure 4.13: Service change requested, accepted 
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MSCB 



Core Network 
Procedure 



Core Network 
Procedure 



UEB 



MODIFY (BCb) 



MODIFY REJECT (BCa) 



Figure 4.14: Service change requested, rejected 

4.2.5 Network-initiated Service cinange in tiie active state 

When the visited MSC of either party can no longer support an ongoing multimedia call, for example due to degraded 
coverage conditions (including UTRAN to GERAN only transitions), the visited MSC of this party shall initiate a 
service-change from multimedia to speech, following the procedures described below. 

If the visited MSC is again able to support the multimedia at a later point in time while the speech call is still ongoing, 
the same visited MSC may initiate a service change from speech to multimedia as stated in TS 22.101 [8]. The details 
for the service change from speech to multimedia are described in section 4.2.5.2. 

For a downgrade from multimedia to speech the visited MSC shall initiate an In-Call Modification procedure towards 
the terminal it serves using the MODIFY message. The visited MSC shall also invoke the service change procedure (see 
clause 4.3.5) towards the remote side. The terminals on both sides will react as described in Clause 4.2.4. 

The Visited MSC shall only initiate a Network Initiated Service Upgrade from speech to multimedia if the terminal has 
indicated support for Network Initiated Service Upgrade Capability during the call establishment phase, as detailed in 
3GPP TS 24.008 [3]. When sending the Modify request to the local terminal the MSC shall include the Network- 
initiated Service Upgrade indicator. A visited MSC receiving an incoming Network Initiated Service Upgrade 
procedure from the core network shall also include the Network-initiated Service Upgrade indicator within the 
MODIFY request to the local terminal. 

NOTE: If the visited MSC initiating the Network Initiated Service Upgrade uses the 3G-324.M codec in the core 
network signalling due to operator's policy, the visited MSC receiving the incoming Service Upgrade 
procedure from the core network will not recognise that this procedure is network-initiated and thus will 
not include the Network-initiated Service Upgrade indicator within the MODIFY request to the local 
terminal. 
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Figure 4.14a: Networlc-lnitiated Service change from multimedia to speech requested, accepted 
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Figure 4.14b: void 



Figure 4.14c: void 
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Figure 4.1 4c1 : Networl<-lnitiated Service cliange from speechi to multimedia requested, accepted 

If the served terminal rejects the service change from speech to multimedia, the initiating MSC shall maintain the 
original service. If the remote side rejects the service change from speech to multimedia, the initiating MSC shall 
initiate a service change procedure towards the served terminal to revert to the original service. 
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Figure 4.14c2: Network-Initiated Service change from speech to multimedia requested, rejected by 

user A 
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Figure 4.14c3: Network-Initiated Service change from speech to multimedia requested, rejected by 

user B 

4.2.5.1 Network-initiated Service change in the active state starting with multimedia 

in lu mode 

For a network initiated service change from multimedia in lu mode to speech, the visited MSC shall use the following 
procedure. 

In order to request a notification from the RNC when it detects a lack of sufficient resources or radio signal degradation, 
the visited MSC shall include an Alternative RAB Parameters IE in the RANAP RAB Assignment Request or RANAP 
Relocation Request message indicating the RAB configuration for speech in addition to the RAB configuration for 
multimedia, when it establishes or modifies the radio access bearer for multimedia at the lu interface. 

When the radio access network detects a lack of sufficient resources to sustain the multimedia RAB configuration, it 
shall inform the visited MSC by sending a RANAP Modify Request message (see 3GPP TS 25.413 [17]) to the visited 
MSC. The visited MSC shall then: 

initiate an In-Call Modification procedure to speech towards the terminal it serves using the MODIFY message; 
and 

invoke the service change procedure (see clause 4.3.5) towards the remote side, 

trigger the RAB modification by sending a RANAP RAB Assignment with the RAB requested to be Modified to 
the RNC. 
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Figure 4.14d: Network-Initiated Service change from UTRAN multimedia to speech requested, 

accepted 

4.2.5.2 Network-initiated Service change in the active state starting with speech in lu 

mode 

The network initiated service change from speech to multimedia in lu mode is an optional feature. If supported the 
MSC initiating the service upgrade to multimedia shall use the following procedure. However a service change from 
speech to multimedia shoud not be initiated unless a network initiated service change from multimedia to speech had 
previously taken place during the same user session. Furthermore a network initiated service upgrade to multimedia 
shall not be performed unless the terminal has indicated that it supports it by including the Enhanced Network-initiated 
ICM (ENICM) Capability at call establishment. If the 3G-324.M2 was not received in the available codec list, 
depending on operator policy, the visited MSC may or may not perform a Network-initiated Service change procedure 
from speech to multimedia. 

NOTE: The 3G-324.M2 codec in the available codec list indicates that all nodes in the call support incoming 
request for the network initiated service change from speech to multimedia and thus collect charging 
information indicating that a network-initiated service change was performed. An operator could choose 
to perform a network-initiated service change even if the 3G-324.M2 codec was not received in the 
available codec list, for example if the operator applies a billing scheme where the initiator of the 
multimedia call pays for the call and mutual agreements with the peer's operator allow this policy. 

In order to request a notification about sufficient resources to sustain again the multimedia RAB configuration from the 
radio access network , the visited MSC shall include an Alternative RAB Parameters IE in the RANAP RAB 
Assignment Request or RANAP Relocation Request message indicating the RAB configuration for multimedia in 
addition to the RAB configuration for speech, when it establishes or modifies the radio access bearer for speech at the 
lu interface during or after a network-initiated service change from multimedia to speech. In order to request a 
notification about sufficient resources from a target RNC after a subsequent relocation, the MSC shall pass the 
Alternative RAB Parameters IE in the RELOCATION REQUEST message to the target RNC. 

NOTE: If the non-anchor RNC is a pre-Release 6 node then no notification about sufficient resources can be 

received and therefore the MSC cannot assume that it will receive the notification for upgrade if it did not 
receive a previous notification for downgrade from that RNC. 

When the radio access network later detects that there are sufficient resources to sustain again the multimedia RAB 
configuration, it shall indicate the possibility of a service change to the alternative multimedia RAB configuration by 
sending a RANAP Modify Request message (see 3GPP TS 25.413 [17]) to the MSC.The MSC may then: 

initiate an In-Call Modification procedure to multimedia towards the terminal it serves using the MODIFY 
message. The visited MSC shall include the NISUid information element in the MODIFY message. The MSC 
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initiating the service change shall not interrupt the user plane until the terminal accepts the modification with a 
MODIFY COMPLETE message. When the MODIFY COMPLETE message is received from the served 
terminal, the initiating MSC shall then: 

invoke the service change procedure (see clause 4.3.5) towards the remote side. The initiating MSC shall then; 

reconfigure the RAB to the multimedia bearer at the latest when receiving a confirmation about the successful 
service change procedure from the remote side. 

When receiving a MODIFY message, a terminal shall not interrupt the data traffic and shall continue to send and 
receive data in the old mode, even after the terminal accepts the modification with a MODIFY COMPLETE message. 
After the radio bearer has been reconfigured by the network, the terminal shall send and receive data in the new mode. 
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Figure 4.2.5.2/1 : Network-Initiated Service change from UTRAN speech to multimedia requested, 
accepted in case the RAB is modified on the initiating side after receiving the response to the service 

change request from the remote side 
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Figure 4.2.5.2/2: Network-Initiated Service change from UTRAN speech to multimedia requested, 
accepted in case the RAB is modified on the initiating side before receiving the response to the 

service change request from the remote side 
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Figure 4.2.5.2/3: Network-Initiated Service change from UTRAN speech to multimedia, RNC B failure 
in case the RAB on the initiating side is not modified before receiving the response to the service 

change request from the remote side 
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Figure 4.2.5.2/4: Network-Initiated Service change from UTRAN speech to multimedia, RNC B failure 
in case the RAB is modified on the initiating side before receiving the response to the service change 

request from the remote side 
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Figure 4.2.5.2/5: Network-Initiated Service change from UTRAN speech to multimedia requested, RNC 
A failure in case the RAB is modified on the initiating side after receiving the response to the service 

change request from the remote side 
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Figure 4.2.5.2/6: Network-Initiated Service change from UTRAN speech to multimedia requested, RNC 
A failure in case the RAB is modified on the initiating side before receiving the response to the 

service change request from the remote side 
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Figure 4.2.5.2/7: Alternative RAB Parameters delivery during the relocation 



4.3 Core Network procedures 



In order to provide the capability in the network to transmit the request for service change (upgrade to multi-media and 
fallback to speech) both at call setup and during the active state of a call, the normal Out-of-Band Transcoder Control 
procedures, described in 3GPP TS 23.153 [2] shall be used. The following text describes the codec type to be used, the 
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mapping between the terminal interface described above, and the different lEs to be used for the codec negotiation 
procedures at both the originating and the terminating MSC. 

4.3.1 Multimedia codec 

The codec negotiation procedures transmit an ordered hst of preferred codecs from the originating to the terminating 
MSC. A node that requires interaction with the user plane will remove the codecs it does not support. The terminating 
MSC shall select the codec to use ("selected codec") from the list of available codecs for the call. This selection shall be 
based on the received list of codecs and on the information given by the terminating UE in the CALL CONFIRMED 

message. 

A dummy codec (defined in 3GPP TS 26.103 [4] for a BICC based CS core network and in 3GPP TS 29.007 [6] as 
dedicated RTP payload types for a SIP-I based CS core network) is included in the codec list to indicate that a 
multimedia call is requested. Two dummy codecs are defined: 

Dummy codec 1 shall be used for a terminal-initiated service change from speech to multimedia. Based on the 
operator policy the dummy codec 1 may be used for the network-initiated service change from speech to 
multimedia, if one of the MSCs has not included the dummy codec 2 to the available codec list during the call 
setup phase. This dummy codec 1 is in the present document referred to as the 3G-324.M codec. It shall be 
supported by any SCUDIF compliant MSC. 

Dummy codec 2 shall be used for a network-initiated service change from speech to multimedia, if all the MSCs 
in the call have indicated the dummy codec 2 in the available codec list during the call setup phase. This codec is 
in the present document referred to as the 3G-324.M2 codec. The 3G-324.M2 codec is identical to the 3G-324.M 
codec except for the CoID. It shall be supported by any SCUDIF compliant MSC that supports a network- 
initiated service change from speech to multimedia. 

NOTE: An Rel-5 MSC does not support the 3G-324.M2 codec. A Rel-6 MSC not supporting the optional 
network-initiated service change procedures could also not support the 3G-324.M2 codec. 

These codec are in the present document referred to as the 3G-324.M codec. 

This codec is only used by the Core Network and shall not be sent from the terminal in the Supported Codec List IE. 

For a BICC based CS core network, the 3G-324.M codec shall be indicated to the MGW as codec media stream 
property in accordance with the3GPP TS 29.232[12]. The 3G-324.M codec shall be indicated to the MGW also if the 
3G-324.M2 codec is selected in Out-of-Band Transcoder Control procedures. The MGW shall treat the User Plane 
configuration (SDU Format) of the 3G-324.M codec as for PCM, as defined in 3GPP TS 26.102 [13]. 

For a SIP-I based CS core network, instead of the 3G-324.M or 3G-324.M2 codecs, the CLEARMODE RTP payload 
type (see IETF RFC 4040 [18]) shall be indicated to the MGW as media type in accordance with the3GPP TS 
29.232[12]. The MGW will treat the user plane for the Clearmode RTP payload type as defined in 3GPP TS 29.007 [6]. 

4.3.2 Originating side - initiation of call setup 
4.3.2.1 Originating MSC Handling 

The originating MSC has a list of supported codec types, listed in order of preference. 

If the SETUP message received from the UE contains a Repeat Indicator with a value of "service change and fallback", 
in addition to a multimedia BC-IE and a speech BC-IE, the MSC shall include a 3G-324.M codec in the list of 
supported codec types according to the following rule: 

If the multimedia BC-IE is listed first, then the 3G-324.M codec shall be the first codec in the list (see 
figure 4.15) If the originating MSC supports a network-initiated service change from speech to multimedia, it 
shall include the 3G-324.M2 codec as second codec in the list. 

If the speech BC-IE is listed first, then the 3G-324.M codec shall be the last codec in the list (see figure 4.16) 
sent by a originating MSC not supporting a network-initiated service change from speech to multimedia. If the 
originating MSC supports a network-initiated service change from speech to multimedia, the 3G-324.M codec 
shall be the last but one codec in the list and the 3G-324.M2 codec shall be the last codec in the list.. In the case 
that the maximum number of codecs is already reached before insertion of the 3G-324M and possibly 3G- 
324.M2 codec(s), the optional speech codec(s) with the least preference shall be replaced by those codec(s). 
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The list shall then be sent according to the Out-of-Band Transcoder Control codec negotiation procedures. The TMR 
field, although mandatory BICC/ISUP parameter, has no meaning when using OoBTC/BICC codec negotiation (the 
link characteristics and QoS are determined from the codec type and signalled to any intermediate switches via the 
bearer control protocol) and thus shall be set arbitrarily to "speech". A transit node that requires interaction with the user 
plane will remove from the list the codecs it does not support. If the 3G-324.M codec is not supported, and thus 
removed, the call shall be turned into a normal speech call (fallback to speech) and follow the normal call setup 
procedures. 



0-UE 



0-MSC 



SETUP (Rl, BCmm, BCsp) 



T-MSC 



(List of Codecs = mm, x, y, z) 



X, y, z: speech codecs. 

mm: dummy multimedia codec 3G-324.I\/I. 

NOTE: If the originating MSC supports incoming requests for a network-initiated service change from speech to 
multimedia, it shall include the 3G-324.M2 codec as second codec in the list after 3G-324.M. This is not 
depicted in the figure. 

Figure 4.15: Multimedia BC as first BC 
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NOTE: If the originating MSC supports incoming requests for a network-initiated service change from speech to 
multimedia, it shall include the 30-324. M2 codec as last codec in the list after 30-324. M. This is not 
depicted in the figure. 

Figure 4.16: Speech BC as first BC 



4.3.2.2 



VMSC Handling at Originating Side 



Depending on operator policy, the VMSC may remove the 3G-324.M2 codec from the list of supported codec types if 
the call is routed to selected other PLMNs. 

NOTE: This enables the operator to block a network initiated upgrade if inter-operator accounting agreements do 
not allow this functionality, e.g. because billing schemes are not compatible for the network-initiated 
upgrade. 



4.3.3 Terminating side 



4.3.3.1 



HLR Interrogation 



The GMSC sends the Send Routing Information request with both the Network Signal Information and Network Signal 
Information 2 parameters. The Network Signal Information shall include the ISDN BC IE for the preferred service, and 
the Network Signal Information 2 includes the ISDN BC IE for the less preferred service. 

The functional behaviour of the HLR is described in 3GPP TS 23.018 [10]. The procedures specific to SCUDIF calls 
are specified in the subclause 4.3.3.1.3 for the HLR and 4.3.3.1.4 for the GMSC. The information elements specific to 
SCUDIF between the GMSC and the HLR are specified in subclauses 4.3.3.1.1 and 4.3.3.1.2. 
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4.3.3.1 .1 Send Routing Info 

The following element specific to SCUDIF calls is defined for Send Routing Info: 



Information element name 


Required 


Description 


ISDNBC2 


C 


ISDN bearer capability 2. Shall be present for a SCUDIF call to 
indicate the less preferred service. 


ISDN LLC 2 


C 


ISDN lower layer compatibility 2. Shall be present for a SCUDIF 
call if necessary for the less preferred service, otherwise shall be 
absent. 


ISDNHLC2 


c 


ISDN higher layer compatibility 2. Shall be present for a SCUDIF 
call if necessary for the less preferred service, otherwise shall be 
absent. 



4.3.3.1 .2 Send Routing Info Ack 

The following elements specific to SCUDIF calls are defined for Send Routing Info Ack: 



Information element name 


Required 


Description 


Roaming number 2 


C 


E.I 64 number required to route the call to VMSCB (see 3GPP 
TS 23.003 [11]) for the less preferred service of a SCUDIF call. 
Shall be present for a SCUDIF call if the preferred service is not 
forwarded (i.e. either Roaming Number is present or the preferred 
service is not allowed) and the less preferred service is allowed 
and not forwarded, otherwise shall be absent. 


Forwarded-to number 2 


C 


E.I 64 number of the C subscriber for the less preferred service of 
a SCUDIF call. Shall be present if the HLR has determined that 
the less preferred service of a SCUDIF call is to be forwarded, 
otherwise shall be absent. 


Long forwarded-to number 2 


c 


Number of the C subscriber (see 3GPP TS 23.082 [1 5]) for the 
less preferred service of a SCUDIF call. Shall be present if the 
HLR has determined that the less preferred service of a SCUDIF 
call is to be forwarded, and GIVISC and HLR support Long 
Forwarded-to Numbers, othenwise shall be absent. 


Forwarded-to subaddress 2 


c 


Subaddress of the C subscriber (see 3GPP TS 23.003 [11]) for the 
less preferred service of a SCUDIF call. Shall be present if the 
HLR has determined that the less preferred service of a SCUDIF 
call is to be forwarded and a forwarded-to subaddress is stored in 
the HLR in association with the forwarded-to number 2, otherwise 
shall be absent. 


Notification to calling party 2 


c 


Indication of whether the calling party is to be notified that the call 
has been forwarded if the less preferred service of a SCUDIF call 
is kept. Shall be present if the HLR has determined that the less 
preferred service of a SCUDIF call is to be forwarded, otherwise 
shall be absent. 


Forwarding reason 2 


c 


Indication of why the call has been forwarded (unconditionally or 
on mobile subscriber not reachable) for the less preferred service 
of a SCUDIF call. Shall be present if the HLR has determined that 
the less preferred service of a SCUDIF call is to be forwarded, 
otherwise shall be absent. 


SS-List 2 


c 


List of SS-codes for the less preferred service of a SCUDIF call. 
Shall be present if the HLR has determined that the less preferred 
service of a SCUDIF call is allowed, otherwise shall be absent. 


Basic Service Code 2 


c 


Indicates the type of the basic service for the less preferred 
service, i.e. teleservice or bearer service. 


Allowed Services 


c 


Shall be present for SCUDIF calls. Indicates which services are 
available for that call. 


Unavailability Cause 


c 


Indicates the reason for which one of the services of a SCUDIF 
call is not available. Shall be present for SCUDIF calls if one 
service is not available. 
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4.3.3.1 .3 Handling of mobile terminating calls in the HLR 

The procedures specific to SCUD IF calls in the HLR are specified within this subclause: 

- Procedure SCUDIF_Subscription_Check_HLR 

- Procedure SCUDIF_CAMEL_CSI_Check_HLR 
Procedure SCUDIF_Set_Second_Service_when_Forwarded 

- Procedure SCUDIF_Set_Correct_PLMN_BC 

Procedure SCUDIF_Check_Second_Service_before_Negative_Response 

- Procedure SCUDIF_Check_Second_Service_after_PRN 
Procedure SCUDIF Check Second Service when Forwarded 



procedure SCUDIFSubscriptionCheckHLR 

: Procedure in the HLR to cliecl< fine subscription for the second : \ 
: service and store the unavailability cause if one of the services '"'\ 
lis not available : 



Allowed Services : 
both 



6 




store Resultfor 
first service 




Jnavailability Cause/ 
negative response 



Allowed Services := 
second Service 



rvice 
*Jetwork Signal Info 2 



6 



SCSC_HLR1(2) 



Figure 4.1 6A: Procedure SCUDIF_Subscription_Check_HLR (sheet 1) 
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procedure SCUDIFSubscriptionCheckHLR 

: Procedure in the HLR to clieck the subscription for tlie second : '•. 
: service and store tine unavailability cause if one of the services '"'\ 
lis not available : 



SCSC_HLR2(2) 



o 



ub script ion_Ctieck 
HLR 




J na vail ability Cause: 
negative response 



legative response := 
legative response foi 
first service 



Allowed Services :■ 
first Service 



Figure 4.16B: Procedure SCUDIF_Subscription_Check_HLR (sheet 2) 
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procedure SCUDIF_CAMEL_CSI_Check_HLR 



: Procedure in Itie HLR to clieck : *•, 

itlie CAMEL data for the second serviced 
: to know if CAMEL is active for that call ; 



(U) 



CAMEL_CSI. 
iUbscription_Chec 



1(1) 



■■: for second service 



Figure 4.16C: Procedure SCUDIF_CAMEL_CSI_Check_HLR 
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procedure SCUDIF_Set_Second_Service_when_forwarded 



: Procedure in the HLR to set tine forwarding :\ 
: intormation to the correctservice for SCUDlP^ 



(U) 




store Forwarding 

nformation for secon( 

Service 



Store Forwarding 

Information for first 

Service 



result := SRI_Ack 



result := continue 



1(1) 



Figure 4.16D: Procedure SCUDIF_Set_Second_Service_when_Forwarded 



ETSI 



3GPP TS 23.172 version 10.0.1 Release 10 



30 



ETSI TS 123 172 VI 0.0.1 (2011-04) 



procedure SCUDIF_Set_Correct_PLMN_BC 

; Procedure in the HLR to always ■,>. 
i set ttie speech PLMN BC for '• 

i SCUDIF calls i 



dJ) 



Copy MSRN for first 

service to MSRN for 

second service 



result := SRI_Acl< 



1(1 



PLMN BC := 

BCtor 

speecin service 



PLMN BC := 

BCfor 

ailowed servi( 




Figure 4.16E: Procedure SCUDIF_Set_Correct_PLMN_BC 
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procedure SCUDIF_Check_second_service_before_Negative_response 



: Procedure in Itie HLR to clieck fine second service : *•, 

: before sending a SRI negative response back to the GMSC\ 



(U) 




restore routeing 
information for 
first service 




negative response : 

negative response 

for first service 



jnavailability cause : 
negative response 



allowed services :■ 
first service 




requested service : 
second signal 
network info 



jnavailability cause : 
negative response 



result :- second 
interrogation 



1(1) 



Figure 4.16F: Procedure SCUDIF_Check_Second_Service_before_Negative_Response 
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procedure SCUDIF_Check_Second_Service_after_PRN 



1(1) 



: Procedure in the HLR to clieck :\ 

llliesecofKl service after PRNresponSH^ 
ihas been received : 



(U) 



store routeing 

information for the 

first service 



requested service : 

second network 

signal info 



second interrogation 



Store routeing 
information for the 
second service 



Figure 4.1 6G: Procedure SCUDIF_Check_Second_Service_after_PRN 
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procedure SCUDlF_Check_Second_Service_when_forwarded 



1(1) 



: Procedure in the HLR to check :\ 
: the second service when a service fe^ 
: forwarded : 



CD) 



store routeing 

information for the 

first service 



requested service 
Network Signal Info 2 



second interogation 



second service 



resUt := continue 



Figure 4.16H: Procedure SCUDIF_Check_Second_Service_when_Forwarded 

4.3.3.1 .4 Handling of mobile terminating calls in the GMSC 

The procedures specific to SCUD IF calls in the GMSC are specified within this subclause: 
Procedure SCUDIF_Negative_SRI_Response_Handling 
Procedure SCUDIF_Check_Service_Availability 
Procedure SCUDIF_Check_Service_Compatibility 
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procedure SCUDIF_Negative_SRI_Response_Handling 



SC_SRI1(1) 



: Procedure in Itie GMSC to liandle : '•. 

: a second interrogation for SCUDIF '"\ 
: call when a negative response is received : 



(U) 



Fallbackto the 
5S preferred servics 



[ itrieve SRI result fror|i 
first interrogation 



Figure 4.161: Procedure SCUDIF_Negative_SRI_Response_Handling 
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procedure SCUDIF_Check_Service_Availability 



Procedure in the GMSC to fallback to a 
single service if one of the services 
of a SCUDiF call is unavailable 




yes 




yes 



Value of Allowed 
services indicator ? 



both 



Fallback to the 
less preferred service 



second service 



first service 



Fallback to the 
preferred service 



-^e 



result := continue 




Store SRI for 
preferred service 



result := second SRI 



SC_S_A1(1) 



yes 



Result is for the less 
preferred service 



result := continue 



Figure 4.1 6J: Procedure SCUDIF_Check_Service_Availability 
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procedure SCUDIF_Check_Service_Compatibility 



SC_S_C1(1) 



Procedure in the GMSC to fallback to t 
single service if tfie services 
of a SCUDIF call fiave different 
destination 




Figure 4.1 6K: Procedure SCUDIF_Check_Service_Compatibility 

4.3.3.1 a GMSC Handling at Terminating Side 

Depending on operator policy, the GMSC may remove the 3G-324.M2 codec from the list of supported codec types if 
the call is received from selected other PLMNs. 

NOTE: This enables the operator to block a network initiated upgrade if inter-operator accounting agreements do 
not allow this functionality, e.g. because billing schemes are not compatible for the network-initiated 
upgrade. 



4.3.3.2 



Terminating MSC Handling 



The terminating MSC receives the list of supported codec types, including the 3G-324.M codec and possibly the 3G- 
324. M2 codec. It shall then send a SETUP message towards the terminating UE including a Repeat Indicator with the 
value "service change and fallback" and two BC-IEs, according to the following rule: 
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if the 3G-324.M codec is the first (preferred) codec in the list of supported codecs, then the first BC-IE in the 
SETUP message is the muhimedia BC-IE, and the second BC-IE is the speech BC-IE (see figure 4.17); 

if the 3G-324.M codec is in the list of supported codec types, but not in the first position, then the first BC-IE in 
the SETUP message is the speech BC-IE, and the second BC-IE is the multimedia BC-IE (see figure 4.18). 

The terminating UE answers according to its capabilities in the CALL CONFIRMED message. The terminating MSC 
shall determine the Selected Codec and construct the list of available codecs according to the following rules: 

If no Repeat Indicator is included, and only a speech BC-IE is received, the MSC shall choose a speech codec as 
the Selected Codec according to the normal mechanism, and no 3G-324.M codec shall be inserted in the list of 
available codecs (see figure 4.19). 

If no Repeat Indicator is included, and only a multimedia BC-IE is received, the MSC shall choose the 
3G-324.M codec as the Selected Codec, and only the 3G-324.M codec shall be inserted in the list of available 
codecs (see figure 4.20). 

If the Repeat Indicator is included, and the speech BC_IE is the first BC-IE and the multimedia BC-IE is the 
second BC-IE, the MSC shall choose a speech codec as the Selected Codec according to the normal mechanism, 
and both the 3G-324.M codec and speech codecs shall be inserted in the list of available codecs (see figure 4.21) 
If the terminating MSC supports incoming requests for a network-initiated service change from speech to 
multimedia and was offered the 3G-324.M2 codec and the terminal had indicated in the CALL CONFIRMED 
message with the"Enhanced Network-initiated ICM" (ENICM) Capability for the support of Network-initiated 
service upgrade to multimedia, the 3G-324.M codec shall be the last but one codec in the list and the 3G-324.M2 
codec shall be the last codec in the list. 

If the Repeat Indicator is included, and the multimedia BC-IE is the first BC-IE and the speech BC-IE is the 
second BC-IE, the Selected Codec shall be the 3G-324.M codec, and both the 3G-324.M codec and speech 
codecs shall be inserted in the list of available codecs (see figure 4.22). If the terminating MSC supports 
incoming requests for a network-initiated service change from speech to multimedia and was offered the 3G- 
324.M2 codec and the terminal had indicated in the CALL CONFIRMED message with the"Enhanced Network- 
initiated ICM" (ENICM) Capability for the support of Network-initiated service upgrade to multimedia, the 
terminating MSC it shall include the 3G-324.M2 codec as second codec in the list of available codecs. 

The Selected Codec and the list of available codecs shall be sent back to the originating MSC according to the normal 
codec negotiation procedure. 



0-MSC 



T-MSC 



(List of Codecs = mm, x, y, z) 



T-UE 



SETUP (Rl, BCmm, BCsp) 



NOTE: The 3G-324.M2 codec may be included the list in addition to 3G-324.IVI. This is not depicted in the figure. 

Figure 4.17: 3G-324M codec first 



0-MSC 



T-MSC 



(List of Codecs = x, y, z, mm) 



T-UE 



SETUP (Rl, BCsp, BCmm) 



NOTE: The 3G-324.M2 codec may be included the list in addition to 3G-324.I\/I. This is not depicted in the figure. 

Figure 4.18: Speech codec first 
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O-MSC 



T-MSC 



(select = X, avail = x, y, z) 



T-UE 



CALL CONFIRMED (BCsp) 



NOTE 



NOTE: The actual speech codec is selected according to OoBTC procedures. 

Figure 4.19: Speech only 



O-MSC 



T-MSC 



(select = mm, avail = mm) 



T-UE 



CALL CONFIRMED (BCmm) 



NOTE: The 3G-324.M2 codec may be included in the list of available codecs after the 3G-324.M codec. This is 
not depicted in the figure. 

Figure 4.20: lUlultimedia only 



O-MSC 



T-MSC 



(select = X, avail = x, y, z, mm) 



T-UE 



CALL CONFIRMED (Rl, BCsp, BCmm) 



NOTE 



NOTE 1 : The actual speech codec is selected according to OoBTC procedures. 

NOTE 2: If the terminating MSC supports incoming requests for a network-initiated service change from speech to 
multimedia and was offered the 3G-324.M2 codec and the terminal had indicated in the CALL 
CONFIRMED message with the"Enhanced Network-initiated ICM" (ENICM) Capability for the support of 
Network-initiated service upgrade to multimedia, the terminating MSC shall include the 3G-324.M2 codec 
as last codec in the list of available codecs after 3G-324.M. This is not depicted in the figure. 

Figure 4.21 : Speech preferred 
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0-MSC 



T-MSC 



(select = mm, avail = mm, x, y, z) 



T-UE 



CALL CONFIRMED (Rl, BCmm, BCsp) 



NOTE 



NOTE 1 : The actual list of speech codecs is built according to OoBTC procedures. 

NOTE 2: If the terminating MSC supports incoming requests for a network-initiated service change from speech to 
multimedia and was offered the 3G-324.M2 codec and the terminal had indicated in the CALL 
CONFIRMED message with the"Enhanced Network-initiated ICM" (ENICM) Capability for the support of 
Network-initiated service upgrade to multimedia, the terminating MSC shall include the 3G-324.M2 codec 
as second codec in the list of available codecs after 3G-324.M. This is not depicted in the figure. 

Figure 4.22: Multimedia preferred 

4.3.4 Originating side - completion of call setup 

The originating MSC receives the Selected Codec and the list of available codecs, and, depending on the active mode, 
shall do the following: 

The call was set up with a multimedia BC-IE first: 

if the Selected Codec is the 3G-324.M codec, no In-Call Modification procedure is necessary (see figure 4.23). If 
no speech codecs are included in the list of available codecs, all In-Call Modification procedures initiated by the 
UE using the speech BC-IE shall be rejected with a MODIFY REJECT message; 

if the Selected Codec is a speech codec, an In-Call Modification procedure to change to speech mode shall take 
place (see figure 4.24). If the 3G-324.M codec is not included in the list of available codecs, all In-Call 
Modification procedures initiated by the UE using the multimedia BC-IE shall be rejected with a MODIFY 
REJECT message. 

The call was set up with a speech BC-IE first: 

if the Selected Codec is the 3G-324.M codec, an In-Call Modification procedure to change to multimedia mode 
shall take place (see figure 4.25). If no speech codecs are included in the list of available codecs, all In-Call 
Modification procedures initiated by the UE using the speech BC-IE shall be rejected with a MODIFY REJECT 

message; 

if the Selected Codec is a speech codec, no In-Call Modification procedure is necessary (see figure 4.26). If the 
3G-324.M codec is not included in the list of available codecs, all In-Call Modification procedures initiated by 
the UE using the multimedia BC-IE shall be rejected with a MODIFY REJECT message. 



0-UE 



0-MSC 



CONNECT 



T-MSC 



(select = mm, avail = mm, x, y, z) 



NOTE 1 , 
NOTE 2 



NOTE 1 : Speech codecs (x, y, z) may or may not be present. If they are not present, subsequent MODIFY requests 

from the UE are rejected. 
NOTE 2: The 3G-324.M2 codec may be included in the list of available codecs after the 3G-324.M codec. This is 

not depicted in the figure. 

Figure 4.23: Multimedia preferred, selected 
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0-UE 



0-MSC 



CONNECT 



MODIFY (BCsp) 



T-MSC 



(select = X, avail = x, y, z, mm) 



N0TE1, 
NOTE 3 



NOTE 2 



NOTE 1 : The multimedia codec (mm) may or may not be present. If it is not present, subsequent l\/IODIFY requests 

from the UE are rejected. 
NOTE 2: see clause 4.2.3 for the In-Call Modification signalling. 
NOTE 3: The 3G-324.M2 codec may be included in the list of available codecs after the 3G-324.M codec. This is 

not depicted in the figure. 

Figure 4.24: Multimedia preferred, speech selected 



O-UE 



0-MSC 



CONNECT 



MODIFY (BCmm) 



T-MSC 



(select = mm, avail = mm, x, y, z) 



NOTE 1, 
NOTE 3 



NOTE 2 



NOTE 1 : Speech codecs (x, y, z) may or may not be present. If they are not present, subsequent MODIFY requests 

from the UE are rejected. 
NOTE 2: see clause 4.2.3 for the In-Call Modification signalling. 
NOTE 3: The 3G-324.M2 codec may be included in the list of available codecs after the 3G-324.M codec. This is 

not depicted in the figure. 

Figure 4.25: Speech preferred, multimedia selected 



O-UE 



0-MSC 



CONNECT 



T-MSC 



(select = X, avail = x, y, z, mm) 



NOTE 1 , 
NOTE 2 



NOTE 1 : The multimedia codec (mm) may or may not be present. If it is not present, subsequent MODIFY requests 

from the UE are rejected. 
NOTE 2: The 3G-324.M2 codec may be included in the list of available codecs after the 3G-324.M codec. This is 

not depicted in the figure. 

Figure 4.26: Speech preferred, selected 

4.3.5 Service change (during tine active state 

Whenever an In-Call Modification procedure is invoked by a terminal, unless it is not allowed as determined at call 
setup, the following shall take place: 

if the current mode is the speech mode and the MODIFY message contains a multimedia BC-IE, the normal 
Out-of-Band Transcoder Control procedures shall be invoked in order to change the Selected Codec to the 
3G-324.M/3G-324.M2 codec; 
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if the current mode is the multimedia mode and the MODIFY message contains a speech BC-IE, the normal 
Out-of-Band Transcoder Control procedures shall be invoked in order to change the Selected Codec to the 
preferred speech codec. 

When a visited MSC invokes Network-initiated Service change in the active state (see Clause 4.2.5), this visited MSC 
shall also invoke the normal Out-of-Band Transcoder Control procedures in order to change the Selected Codec to 
speech or to the 3G-324.M/3G-324.M2 codec, respectively. 

For a User-initiated service change from speech to multimedia, the visited MSC shall use the 3G-324.M codec as 
Selected Codec. 

If the visited MSC received the 3G-324.M2 codec in the available codec list, the visited MSC shall use the 3G-324.M2 
codec as Selected Codec for a Network-initiated Service change procedure from speech to multimedia. 

If the visited MSC did not receive the 3G-324.M2 codec in the available codec list, depending on operator policy, the 
visited MSC may either use the 3G-324.M codec as Selected Codec for a Network-initiated Service change procedure 
from speech to multimedia, or the visited MSC may not perform a Network-initiated Service change procedure from 
speech to multimedia. 

NOTE: The the 3G-324.M2 codec in the available codec list indicates that all nodes in the call support collecting 
appropriate charging records for the network initiated service change from speech to multimedia. 

If the 3G-324.M2 codec is used as Selected Codec in BICC signalling, the 3G-324.M codec shall be signalled instead to 
the MGW. 

NOTE: This avoids that MGWs need to support the 3G-324.M2 codec. 

The Codec Modification procedure shall be supported for service change. The use of mid-call codec negotiation 
procedure is optional for service change. 

When a MSC detects through an Out-of-Band Transcoder Control procedure that the selected codec has changed from a 
speech codec to the 3G-324.M codec, or vice-versa, it shall initiate an In-Call Modification procedure towards the UE 
with a MODIFY message containing the multimedia BC-IE (or the speech BC-IE), unless the new mode has been 
denied at call setup (see clause 4.2.4). 

4.3.5.1 Mid-Call Codec Modification Procedure For Service Change 

The Codec Modification procedures as defined in 3GPP TS 23.153 [2] shall be applied with the following specific 
additional rules for the Service Change procedure. 

In order to prevent the MGW generating an error or seizing resources during the interim period, when its terminations 
are being altered and it may have a speech codec on one side of the context and the 3G-324M codec on the other side 
the Server shall modify the Stream-mode of the affected terminations to inactive during the Service change and shall 
restore the stream mode to active - (send/receive - bothway) on completion of the service change procedure. In order to 
restore the stream mode to active, the MSC servers shall use the 'Modify Bearer Characteristics' procedure for lu 
terminations and for Nb terminations towards the succeeding node with respect to the 'Modify Codec' message. The 
MSC servers shall use the 'Confirm Bearer Characteristics' procedure for Nb terminations towards the preceding node 
with respect to the 'Modify Codec' message. 

If the affected termination"s stream mode is inactive a MGW shall not reject a 'Modify Bearer Characteristics' or a 
'Reserve Bearer Characteristics' procedure because the multimedia codec and a speech codec are interconnected 
simultaneously in the same context. 

For a service change where the CN shall initiate the luUP on the Nb interface, the MSC server terminating the service 
change shall trigger the luUP initialisation towards the core network by setting the luUP initialisation direction to 'out' 
in the 'Confirm Bearer Characteristics' procedure for the corresponding termination towards the core network. 

Example call flows are shown in Figure 4.3.5.1/1 to 4.3.5.1/10. 
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Figure 4.3.5.1/1 : Service change speech to lUlulUle 
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Figure 4.3.5.1/2: Service change speech to IVIulVIe (continued) 
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Figure 4.3.5.1/3: Service change iUiulUle to AIUIR 



ETSI 



3GPP TS 23.172 version 10.0.1 Release 10 



45 



ETSI TS 123 172 VI 0.0.1 (2011-04) 



RNC-A 



MSC-A 



Di] ect Transfer (Modify _Com Dlt te (speec i) 



Server B 



MGW-A 



MGW-B 



Optionally to decrease 
bandwidth 



Succi;ss 



Modify 



Cdnftrm Beare ■ CI lar (Stream Mode=ACT [V E, New C 5d 

► 



Modify Bearer 



Modify Bearer 



ful Codec Modifica 



B( arer Characteristics 



viodify Bt ar sr Ctiaracteristics (5 trt am Mode 



Rt quest 



Ack 



Succ 



Modify 



ss] ul Codec Modification 



Be irer Cliaracteristics (S[n!aiiMode=AC'TVE, codec = AMR) 



MSC-C 



Modify Bearer Ri iqi lest 



Modify Bearer A :k 



inlirm 



MGW-C 



Modify 
(Stream 



Be arer Cliaracteristicf 
Iviode=ACTIVE, cot ec = AMR) 



Bearei 

AMR 



C lar (Stream Mode= 



RNCC 



ACTIVE, New 



c = AMR) 



Optionally to decrease 
bandwidth 



(Stream Mo de= ACTIVE, codec = AMR) 



;TIVE, codec = AMR) 



Figure 4.3.5.1/4: Service chiange IVIulVIe to AIVIR (continued) 
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Figure 4.3.5.1/5: Service change lUiulUleto PCIU1(G.711) 
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Figure 4.3.5.1/6: Service change IVIulUle to PCI\fl(G.711) (continued) 
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Figure 4.3.5.1/7: Network-initiated service change from lUlulUle to speech 
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Figure 4.3.5.1/8: Network-initiated service chiange from IVIulUle to speech) (continue) 
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Figure 4.3.5.1/9: Network-initiated service change speech to IVIulVIe 
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4.3.5.2 



Figure 4.3.5.1/10: Network-initiated service change speech to IVIulVIe (continued) 



Unsuccessful Service Change 



In the case the service change is denied by the UE at the terminating side, the procedures for the unsuccessful Codec 
Modification as defined in [2] shall be applied to revert to the old medium (speech or multimedia). 

The through-connection of terminations shall be performed as described in Subclause 4.3.5.1. The "Codec Modification 
Failure" message shall interact with the "Modify Bearer Characteristics" procedure and the "Confirm Bearer 
Characteristics" procedure in the same way as the 'Successful Codec Modification' message. 

An example sequence is shown in Figure 4.3.5.2/1 to 4.3.5.2/5. 
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Figure 4.3.5.2/1 :Service Change Rejected 
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Figure 4.3.5.2/2 :Service Change Rejected (Continued) 
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Figure 4.3.5.2/4: Networl<-initiated service chiange from speech to IVIulVIe initiated by IVISS A, rejected 

by user B 
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Figure 4.3.5.2/5: Network-initiated service change from speech to IVIulVIe initiated by IVISS A, rejected 

by user B (continued) 

4.3.6 Interaction with supplementary services 



4.3.6.1 



Call forwarding and Call deflection 



If CFB(UDUB), CFNRy, or Call Deflection is invoked in a SCUDIF call, and both basic services are provisioned, the 
HLR (for early call forwarding) or VLR (for late call forwarding) shall check the handling of the call should continue 
with the active service negotiated between the called UE and the network. 

If call forwarding except CFB(UDUB) and CFNRy is invoked in a SCUDIF call, and both basic services are 
provisioned, the HLR (for early call forwarding) or VLR (for late call forwarding) shall check the service for both the 
preferred service and the less preferred service. 

Then, the SCUDIF call interacting with call forwarding shall be handled according to the following rules: 

If the call forwarding is active only for the less preferred service, the preferred service shall be selected and the 
call setup shall continue with a single service without invoking call forwarding. 
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If the call forwarding is active only for the preferred service, the preferred service shall be selected and call 
forwarding shall continue with a single service to the destination indicated by the forwarded to number. 

If the call forwarding is active for both services and the forwarded to number for the preferred service is same as 
for the less preferred service, the call shall continue as a SCUDIF call to the destination indicated by the 
forwarded to number. 

If the call forwarding is active for both services and the forwarded to number for the preferred service is different 
from that for the less preferred service, the preferred service shall be selected and call forwarding shall continue 
with a single service to the destination indicated by the forwarded to number for the preferred service. 

If the call forwarding is active for both services and CF type for the preferred service is different from that of 
less preferred service, the call shall continue as a SCUDIF call to the destination indicated by the forwarded to 
number, and the forwarding reason for the preferred service shall be indicated. 

NOTE: For Late call forwarding or Call Deflection with Optimal Routing, the second basic service group code 
shall be generated in VMSC and sent in Resume Call Handling and may be sent in the following Send 
Routing Information. The preferred service is set as basic service group IE, and the less preferred service 
is set as basic service group 2 IE. 

4.3.6.2 Closed User Group (CUG) 

If a SCUDIF call interacts with CUG and both basic services are provisioned, the service state shall be checked for both 
the preferred service and the less preferred service. If one service is not allowed, then the call shall fall back to the 
allowed service. 

4.3.6.3 Gall barring 

If a SCUDIF call interacts with call barring and both basic services are provisioned, the service state shall be checked 
for both the preferred service and the less preferred service. If one service is barred, then the call shall fall back to the 
allowed service. 

4.3.7 Interactions with CAMEL 

4.3.7.1 Interaction at call setup 

When a SCUDIF call activates a CAMEL dialogue for the originating or the terminating subscriber, both basic services 
shall be indicated to the gsmSCF in the InitialDP message (see 3GPP TS 23.078 [14]) : 

the bearer capability IE and the ext -basic service code IE shall indicate the preferred service (i.e. 3G-324.M if 
the 3G-324.M codec is the first codec in the list of supported codecs ; speech otherwise), 

the bearer capability 2 IE and the ext-basic service code 2 IE shall indicate the other, less preferred service (i.e. 
resp. speech or 3G-324.M). 

4.3.7.2 Interaction at call answer 

When the Answer DP is triggered according to the BCSM (see 3GPP TS 23.078 [14]), the event report sent to the 
gsmSCF shall indicate the result from the OoBTC codec negotiation procedure according to the following : 

the ext-basic service code IE is included, and represents the selected service (indicated by the selected codec) ; 

the ext-basic service code 2 IE is included if the list of available codecs contains codecs both for speech and 3G- 
324. M, and represents the other service (i.e. speech if the selected service is 3G-324.M, and vice-versa). 

4.3.7.3 Interaction with Call Party Handling 

Interaction with Call Party Handling is allowed, when the call is a speech call and it cannot become a multimedia call. 
See 3GPP TS 22.078 [16] clause 21. 
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4.3.7.4 Interaction with CAMEL in-band information and user interaction 

Interaction with Camel in-band information and user interaction is allowed, when the call is a speech call and it cannot 
become a multimedia call. 

See 3GPP TS 22.078 [16] clause 21. 

4.3.7.5 Interaction during service change 

When a service change is successfully completed (i.e. the codec modification or mid-call codec negotiation reply 
message indicates a successful codec modification), and the 0_Service_Change DP or the T_Service_Change DP is 
armed, then the relevant detection point is triggered (see 3GPP TS 23.078 [14]). 

When a service change is rejected (i.e. the codec modification or mid-call codec negotiation reply message indicates a 
failure), then the previously selected service is kept, and no event report shall be sent to the gsmSCF for the 
0_Service_Change DP and the T_Service_Change DP. 

4.3.8 Interworking with external networks 

If the 3G-324.M codec is included in the list of supported codec types received by a Gateway MSC, and the external 
network does not support BICC or does not support Codec Negotiation, the Gateway MSC shall terminate the codec 
negotiation and fallback to a single service. 

NOTE 1 : If the route is known not to support the SCUDIF functionality, the Gateway MSC may decide by 
configuration to terminate the codec negotiation and follow the procedure described in this clause. 

In the case where the 3G-324.M codec is the first in the list, the network decides by configuration to fallback either to a 
UDI multimedia-only call or to speech. In the case where the 3G-324.M codec is not the first on the list, the call shall 
fallback to speech only. 

If fallback to multimedia occurs, the call control parameters sent towards the external network shall be set according to 
the setting for multimedia calls, and TMR is set to "64 kbit/s unrestricted". The 3G-324.M codec shall be returned to the 
originating MSC server as the selected codec and be the only member of the available codec list. 

NOTE 2: For multimedia calls, 3GPP TS 27.001 [5], annex B, and 3GPP TS 29.007 [6], table 7A, describe the 
setting and validity of the PLMN BC-IE as well as the comparable settings of parameters in the PLMN 
and ISDN BC-IEs. As the ISDN BC-IE parameter values used for UDI/RDI multimedia calls are identical 
to the BICC USI IE parameter values (see 3GPP TS 29.205 [7]), the setting of call control parameters 
sent towards the external network in case of fallback to multimedia can be derived straightforward. 

If fallback to speech occurs, the call control parameters shall be set according to the setting for speech calls, and TMR is 
set to "speech". The 3G-324.M codec shall be removed from the available codec list. Speech codec selection shall be 
made according to normal OoBTC procedures for interworking to external networks, and the selected codec and 
available codec list returned to the originating MSC server. 

4.3.9 User interaction and in-band information 

The MSC provided announcements and tones do not work, if the negotiated BC is a multimedia BC. Most often the in- 
band information is connected to the originating UE but the same rules apply for the terminating UE. The following 
rules apply: 

1) Before sending the CONNECT message the originating MSC may insert in-band information if CALL 
PROCEEDING message indicates speech as the selected or preferred service. When fallback to multimedia 
occurs after CALL PROCEEDING but before CONNECT, the MSC may insert in-band information. 

2) Before sending the CONNECT message the originating MSC shall not insert in-band information, if CALL 
PROCEEDING message indicates multimedia as the selected or preferred service. When fallback to speech 
occurs after CALL PROCEEDING but before CONNECT, the MSC shall not insert in-band information. 

3) After the CONNECT message to/from the UE the originating/terminating MSC may insert in-band information, 
if the selected service is speech. Otherwise, the MSC shall not insert any in-band information. As an option, if 
the call is to be cleared, the MSC may perform an in-call modification to speech prior to the insertion of the in- 
band information. 
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4) During the call setup phase the terminating MSC, transit MSC and GMSC may insert in-band information, if the 
selected/preferred service received from the originating switch is speech. Otherwise the terminating MSC, transit 
MSC and GMSC shall not insert any in-band information during the call setup phase. 

5) In the active phase of the call the terminating MSC, transit MSC and GMSC may insert in-band information, if 
the selected service is speech. Otherwise the terminating MSC, transit MSC and GMSC shall not insert any in- 
band information. As an option, if the call is to be cleared, the terminating MSC, transit MSC or GMSC may 
perform an in-call modification to speech prior to insertion of the in-band information. 



Lawful Interception 



SCUDIF calls shall be monitored as for normal Circuit Switched data calls, for detailed requirements see 3GPP TS 
33.106 [9]. 
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